The present invention relates to signalling techniques aimed at achieving a certain Quality of Service (QoS) for packet transmission networks such as the Internet. In particular, the invention relates to networks operating under the IP protocol (Internet Protocol, see Request for Comments (RFC) 791 published in September 1981 by the Internet Engineering Task Force (IETF)).
It is known that IP networks transport data in the form of packets or datagrams under a mechanism known as “best effort”.
Several enhancements have been proposed for the IP protocol in the network layer of the OSI model, for providing much greater quality of service in certain information flows.
Some of these techniques (“Diffserv”, see RFC 2474 and 2475 published in December 1998 by the IETF) use special marking of packets at the network boundary, chiefly with the aid of the TOS (Type of Service) field in the IP header. The network's internal routers do not differentiate the flows in terms of quality of service, but only the classes of packets specified by the markings.
The invention rather relates to techniques (“Intserv”, see RFC 1633 published in June 1994 by the IETF) that reserve resources in the routers based on the flows processed, which can be identified by the source and destination IP addresses, and the port numbers of the transport protocol layer. The invention is aimed more specifically at those of these techniques that dynamically reserve resources. The most common of these is the RSVP protocol (“Resource reSerVation Protocol”, see RFC 2205 published in September 1997 by the IETF).
The resources undergoing such dynamic reservation depend on the specific implementations of the protocol. They may correspond, for example, to portions of bandwidth, or to portions of packet buffer memories.
Reserving such resources requires signalling procedures to establish and maintain states in the routers encountered along the packet path in the network. These procedures entail transmitting special datagrams along the path. Packet routing then takes place taking into account the states thus established and maintained.
RFC 2746, “RSVP Operation over IP Tunnels”, published in January 2000 by the IETF describes how to implement RSVP in IP tunnels carrying IP traffic (see also EP-A-1 035 688). This IP traffic is in the form of datagrams of an inner IP layer, or IP application layer. The “tunnel” is formed between two routers of this outer layer, where these datagrams are encapsulated in the datagrams of an outer IP layer, or IP transport layer, linking up these two routers (this outer layer is viewed as belonging to level 2 of the OSI model from the inner layer). The above documents describe how to associate RSVP sessions of the inner layer with RSVP sessions of the outer layer in response to the detection of outer layer signalling datagrams by the tunnel end routers.
The RFC 2746 mechanism is based on an observation of the datagrams of the inner layer at the two ends of the tunnel and on specific information exchanges between the routers located at these endpoints. It is not applicable when one of the tunnel ends is not capable of analysing the IP datagram headers of the inner layer.
Yet there are network architectures that use IP tunnels for carrying IP traffic without the ends of these tunnels having the ability to analyse IP traffic as a matter of course. The aforementioned mechanism then proves deficient.
This situation is encountered especially in cellular radio communication networks enabling wireless access to packet networks, especially of the IP type (Intranet or Internet). Some second generation cellular networks (GSM, Global System for Mobile communications) now include a packet transmission service called GPRS (General Packet Radio Service). The third generation cellular systems, especially UMTS (Universal Mobile Telecommunications System), are designed with multimedia in mind, and therefore incorporate such packet transmission services.
These cellular systems include a core network performing communication and user management functions, and one or more radio access networks that supply the links between the infrastructure and the radio terminals.
In the aforementioned systems (GPRS, UMTS), the core network is based on IP technology. Accordingly, when a terminal exchanges data in the form of IP datagrams, these data undergo double IP encapsulation in the core network. An inner IP layer links the radio terminal with the packet network (Internet or Intranet). A core network switch, called a GGSN (Gateway GPRS Support Node) forms the packet network edge router with which the terminal exchanges its IP datagrams in a single hop of the inner IP layer. In the core network, these IP datagrams are incorporated into data units of a GTP tunnelling protocol (GPRS Tunnelling Protocol, see technical specification 3GPP TS 29.060, version 3.8.0 published in March 2001 by the 3GPP (3rd Generation Partnership Project)), themselves encapsulated in datagrams of an outer IP layer linking the GGSN with the terminal serving switch called an SGSN (Serving GPRS Support Node).
The IP/GTP/IP tunnel extends from the GGSN to the SGSN. One of its ends (the SGSN) does not have the functionalities of an inner IP layer router. In particular, it does not have the ability of the GGSN to analyse the header and possibly a part of the data of the inner IP layer datagrams.
In a typical scenario, an “Intserv” service such as RSVP is provided between one terminal and another terminal or remote server connected to the packet network (Internet or Intranet). The signalling datagrams are thus processed by the routers of the inner IP layer, which can reserve the required resources if they are available. A weak link in this chain may be the outer IP layer between the GGSN and the SGSN, which generally applies to a “best-effort” mechanism. In fact, a mesh network may exist between the GGSN and the SGSN comprising a large number of routers.
As the SGSN does not have this functionality of analysing the IP datagram headers of the inner IP layer, the RFC 2746 mechanism is not applicable in the tunnel.
Giving SGSNs an ability to analyse the data fields (payload) of the outer IP layer datagrams for the sole purpose of detecting possible RSVP signalling packets from the inner IP layer would be a very complex and costly solution, noting that these RSVP packets represent only a very small fraction of the total traffic.
Accordingly, the RSVP signalling relay mechanism suggested in RFC 2746 and EP-A-1 035 688 cannot be applied to cellular networks. Thus, the traffic in the core network, including the traffic that mostly makes do with “best-effort” service, may hinder supplying the quality of service required for an RSVP flow. This reduces the ability of the cellular operator to offer its customers dynamically reserved “Intserv” services.
In “Supporting IP QoS in the General Packet Radio Service”, (IEEE Network, September/October 2000, pp. 8-17), G. Priggouris et al. describe an adaptation of a GPRS network for providing Diffserv and Intserv type services. According to this article, the GGSN responds to the receiving of a PATH packet of the RSVP protocol in the inner IP layer by sending to the SGSN an initialization message of another RSVP session in the outer layer. Such operation requires a non-standard implementation of RSVP in the outer layer, which complicates the design of the SGSN especially. Moreover it leads to, in an under-optimum way, triggering steps for establishing a tunnel as the reservation may fail in the outer layer.